A Graphic Finish Line System
for Pinewood Derby Racing
by Stan Pope
Summary
This document describes a Local web-enabled Graphical adjunct to Pinewood Derby Race Management Software
which provides an economical visual display of race heat results which can be viewed on a central display
or on personal devices by attendees using a WIFI connection to a "Private" (i.e. not web connected)
Local Area Network. Facilities include precision display of heat results including heat elapsed time
and place for each race car, automatic identification of each race car, coordination
with various race management software systems, and facilities for following specific race cars on personal
devices.
The author does not claim to have resolved all technical issues or to provide detail electronic designs
which would implement the concepts. Rather the author provides a conceptual overview of possibilities
which, in his opinion, are feasible and which offer a vastly improved spectator solution to viewing
Pinewood Derby racing.
System Components
Starting Line
The starting gate is "snap open", such as the gate provided by MicroWizard in which the gate is held closed
by a latch and when the latch is released, the gate is opened by springs more quickly than the cars can react.
An electrical signal is linked from the starting gate to the finish line electronics which indicates the precise
time at which the gate started opening. (This arrangement should be familiar to users of electronically timed
racing.)
Finish Line Sensors
The finish line is "photographed" at intervals of about 500 microseconds. I think that intervals ranging
from 100 microseconds to 1000 microseconds are feasible. The "photograph" is 1 pixel wide by 1000 to 2000
pixels long which span the width of the track.
The device used for imaging is a (CMOS) linear image (Line-Scan) array such as the
Hamamatsu CMOS linear
image sensor S11639
Recording of the finish line image frames begins when the start
gate opens and continues until all race cars have fully passed the finish line (or the finish line judge
signals heat completion.) Each finish line frame is associated to a specific interval during the heat.
Finish Line Data Composition
A microprocessor in the finish line module gathers each frame, associates its interval number to each,
and disposes the result. Two options are viable:
1. The microprocessor acts as a USB device and sends the data, frame by frame to a host computer. This
mode is viable when one track is being served.
2. The microprocessor gathers the frames into a large local memory and acts as a LAN node to send the
completed race record via ethernet to a host computer. This mode is more usable when multiple tracks
are being served.
In either case, the microprocessor can (and probably should) remove successive identical frames since
for most of the heat duration, no cars are crossing the finish line!
Host Computer Track Service function
The Host Computer collects the complete heat image and after creating an identity for the image,
stores it in long term memory, e.g. as a file on a local hard drive. The "identity" should include
(1) the track on which the heat occurred, (2) the heat serial number on that track, and may include
a time stamp for the heat.
Host Computer Heat Analysis function 1
If race car identification stickers are used, the host computer will decode the identification stickers
and record the association of track id, heat id, lane id and race car id in a database. Stickers could
be a 5X5 array of black/white spots which encode the race car number, including row and column parity
checking. (The pattern of QR coding on a reduced scale might be used.) Depending on the race management
software, if any, in use the host computer will check race car numbers in each lane against the scheduled
heat participants and alarm on discrepancies.
Host Computer Heat Analysis function 2
Regardless of race car identification, the host computer will identify the frame interval in which
each lane's race car first appeared in the finish line frame. From that frame number and the
microseconds per frame characteristic of the finish line sensor, the host will compute the heat
elapsed time for each lane. Optionally, the host will use the car length, wheel size or id sticker size
to compute the speed at which the car crossed the finish line. Heat times will be recorded in a database.
Optionally, depending on the race management software, heat times will be reported to that software.
If both front and rear wheels are visible, a small bit of computation could measure the distance between
them, compute average speed as each transits the finish line and, assuming 5 ounce weight,
compute the coefficient of friction acting on the car during its finish line transit!
Host Computer Heat Display function 1
The primary display of heats will show race cars apparently moving left to right across the display in
their lanes. Each lane will include the heat finish order, the race car number if available, the frame
number in which the car first appeared at the finish line, the heat elapsed time, and the speed at which
the car passed the finish line. Gaps between race cars, if any, may be compressed to maximize the detail
in the displayed finish image. Note that fast moving race cars will appear in fewer finish line frames
than slower moving race cars and will, therefore, appear shorter than slower moving race cars in the
displayed image. This is a display that most users of personal devices would like to save to their device.
|
This looks like it might be a photograph taken as the first car crossed the finish line with some text
superimposed. It isn't. It is actually a composite of hundreds of 1 pixel wide images of the finish
line stacked side by side with some text superimposed. Note the slight elongation of the slower cars!
|
Host Computer Heat Display function 2
When heats are closely contested, the vicinity of the race car's noses can be displayed with a 1 pixel
wide witness line appearing across the track corresponding to the nose position-time of each. In addition
to the identity (or lane number) of the race car's involved, the number of pixels separating the witness
lines and the corresponding heat time difference are displayed.
Host Computer LAN Service
The host computer will use software such as APACHE server management functions and to gather data from
finish lines via ethernet (hard
wired network). A 100 Mb ethernet should be sufficient to collect heat images from a dozen tracks
each using 200 microsecond by 1000 pixel frame sizes.
In addition, the LAN will include WIFI access points arranged in
a pattern to minimize interference. For those portions of the audience in the immediate vicinity of the
tracks, two techniques can be used to provide enough capacity to accommodate the audience needs. First, the
separate access point channels may be separated by 5 or 6 channels numbers (signal width is substantially
larger than channel width, and separating the access point channels will minimize adjacent channel
interference. Second, the access point antennas can be fitted with directive reflectors, e.g. corner
reflectors, which will cause the access point to be much more sensitive to those devices directly in front
of the antenna than to those devices off to either side. Ideally, WIFI access points are on a separate
ethernet than management and finish lines.
Host Computer Management functions
Management functions include (1) Track Configuration (adding tracks to or removing tracks from the network,
(2) recording general information for display such as racing status, including which groups are racing and
where they are in the competition and when the next group is expected to start racing, (3) displaying heat
results (see "Host Computer Heat Display function 1") on large displays.
Host Computer Personal Device Service functions
The host computer can respond to anonymous personal device requests for
(1) General information posted by the race managers, (2) Current status information, (3) Graphic for the
last heat that involved a specific race car, (4) the next graphic for a specific race car after the last
graphic displayed.
Permanent Record
At completion of racing, the files and databases comprise a comprehensive record of the event.
These files and databases will be moved to a server on the internet from which displays comparable to those
served to personal devices during the event!
Finish Line Camera Alignment
Since the Finish Line Camera has a one-pixel wide view of the finish line, alignment of the camera is both
important and not apparent from a normal image.
It is important that the camera be aligned correctly to the finish line at the start of racing and that each
heat image show that the camera alignment has been maintained. A technique that supports both of these needs
is to place a black triangle at each end of the finish line. The triangle dimensions could be on the order
of 44 pixels high and 41 pixels wide at the base. The triangle has a 1 pixel wide X 4 pixel high white spot
centered on the base and height. A triangle is placed at each end of the finish line outside the path of the
cars with the 1X4 pixel white bar is carefully aligned to the finish line. When the camera is properly
aligned both top and bottom of the frame consists of two 20 pixel black bars separated by a 4 pixel white bar.
Absent the white medial bar, the bar height tells the direction of the misalignment.
The finish line microprocessor should include a switch for "Alignment Mode" and a push button which will
cause the microprocessor to send a 10 frame burst to the host computer with the "Alignment mode" tag and
track id included in the burst. Alignment mode must be automatically suppressed while a heat is in progress.
The finish line must include a visible signal that the finish line is in alignment mode.
This aspect needs to revisited when I have better data on camera support stability.
Comparisons
As compared to typical race management displays, full implementation of this method tells which race cars
actually raced and shows graphically and numerically how each performed. Mast race management records show
only which race cars were supposed to race in each lane of each heat and the elapsed heat time for the race
cars that actually raced. This method shows, for each race car, the identity of the race car in each lane,
its actual heat elapsed time, its average speed for the entire heat, and its average speed as it crosses
the finish line.
As compared to typical race management displays with video clips of the finish, full implementation of this
method provides greater clarity of the actual finish. With 32 fps video clips, race cars move several
inches between frames and may appear fuzzy in the display. With this method, race cars move approximately
0.01 to 0.10 inches per frame depending on the frame rate used by the finish line.
The clearer image of finish is provided at much
reduced data space, making individual display and data capture by personal devices feasible.
Numbers
Here are some approximate size/capacity numbers assuming
250 microseconds interval for finish line images,
2000 pixels per finish line frame,
10 mph (176 inches/second) race car speed as it crosses the finish line,
7 inch race car length,
1.18" diameter wheels,
3 lanes per track, and
3.200 second heat times.
Uncompressed heat image size: 25.6 megapixels/heat
= 3.200 seconds/heat * (1,000,000/250) frames/second * 2000 pixels/frame
Compressed heat image frames, dropping redundant empty frames
(worst case with car separations exceeding 1 car length): 480 frames
= (7 inches per car / ( 176 inches/second * (250/1,000,000) seconds/frame ) + 1) * 3 cars per track) -1 frame)
This size suggests compressing the track width from 2000 pixels to 500 pixels for display,
producing a 240,000 pixel images to pass around the WIFI LAN!
Compressed heat image size, dropping redundant empty frames
(worst case with car separations exceeding 1 car length): 0.96 megapixels/heat
= 480 franes * 2000 pixels/frame.
At 8 bit/pixel this is 0.96 MB of data per heat.
Further compression is possible within each frame.
For instance, next byte in output:
bit 0=0: bits 1-7 tell next how many bytes are presented as data;
bit 0=1: bits 1-7 tell how many bytes to copy from corresponding positions in prior frame.
Worst case is 1% increase.
Speed computation granularity:
At 176 inches/second a 1.18" wheel occupies about 27 frames. A 1 frame difference in measured speed is about 4%.
To make wheel speed computation based on wheels, the frame rate must be increased to about 10000 frames/second or
100 microseconds/frame.
At 176 inches/second a 7" car occupies about 159 frames. A 1 frame difference in measured speed is a more acceptable 0.6%
Originally Created: 3/10/2014
Copyright 2014 © by Stan Pope. All rights reserved.